Business Process Design (BPD) targets the structuring of activities or tasks within a business with the goal of producing an intended outcome of value to its users or customers. BPD can be performed on various different levels of abstraction targeting a spectrum different of users spanning from roles such as business analysts, business subject-matter experts, business data managers, developers, testers, administrators, IT professionals, etc.
For example, from a business perspective, defining process steps, roles assigned to these steps and the order of these can be the focus of one point of view. Defining specifically the connection of the process and its activities to sources of data, required data transformations, detailed control and data flow, output data, or the like may be the focus of another, such as an IT oriented view of the process definition. Each presentation caters to a different target audience or persona.
In current BPD practices, the common problem is that business analysts today often perform the process design “in a vacuum”; i.e. disconnected from actually executing process and the existing IT artifacts that enable their execution. This main problem lies in the missing common vocabulary between the business users and IT developers. These typical practices limit their ability to trace process designs from a business level concept down to code and deployment artifacts. They also prevent business users from directly affecting changes to existing process designs—be it on process instance or process type level.
For example, typical problems that frequently occur but need to be prevented through appropriate guidance of the process design are: (1). missing data or process artifact; (2). a required entity for the implementation of a task is not available in its data context; (3). an ambiguous entity; (4). a required entity is available, but with multiple instances; (5). the appropriate instance needs to be selected or disambiguated; (6). a conflicting entity; (7). a specific instance is available in the data context but violates a certain constraint against the availability of another entity; (8). only conditionally or optionally available entity; (9). if a certain entity can only be acquired into the data context by performing a task on a conditional path of the workflow, then subsequent tasks operating on the respective entity need to be flagged as potentially incomplete; or (10). authorization and access levels constraints.
Using a simple illustration, suppose a user assigns an order from a customer in region B to a manager1 in region A after the order is received. In order for the manager1 in region A to handle and process the order from region B, the manager1 needs to obtain an authorization from a manager2 at the sales department in region B. However, when the user assigns this order to manager1, the user failed to include an activity such as “obtaining authorization from manager2” in the workflow context. Without any alert or error message, the user would assume what he has done would seamlessly be executed. However, during the execution and when the manager1 receives such task, the manager1 could not proceed further without the authorization. As such, the entire workflow would require additional exception handling and reconfiguration.
While the existing application programs facilitate the creation of such workflow context, these programs usually fail to indicate if there is anything wrong or incomplete among the different tasks or the individuals involved during design time. The existing implementations of process-oriented programs typically fail to indicate whether the tasks may be performed until when the workflow is in execution. Typically, the existing application programs permit the users to design such workflow activities, and the users would only find that parts of the workflow could not be completed because of missing information during execution time. In addition, in order to accomplish such validations, the user is required to model the data flow on top of the control flow. Typically, this leads to a level of technical complexity that goes beyond the typical business user expectation. Other systems or application programs would merely attempt to ensure that the data used is always consistent during the manipulation of data.